Module 5: Connecting Networks - Advanced Architecting on AWS

🎯 Module Objectives

Design advanced Transit Gateway architectures (peering, multicast, Connect)
Compare VPC Peering vs. Transit Gateway for VPC connectivity
Implement AWS PrivateLink for service exposure
Understand cross-region PrivateLink (NEW — Nov 2025)
Design shared VPC architectures with RAM

🔀 Transit Gateway Advanced Features

Feature	Description	Use Case
TGW Peering	Connect TGWs across Regions (inter-region) or accounts	Multi-region hub-and-spoke
Multicast	One-to-many traffic distribution via IGMP	Financial data feeds, media streaming
TGW Connect	GRE + BGP attachment for SD-WAN appliances	Third-party SD-WAN integration
Network Manager	Global view of TGW topology and routing	Centralized network monitoring
Route Table Segmentation	Multiple route tables per TGW	Isolate prod/dev while sharing services

🔗 VPC Peering vs. Transit Gateway

Aspect	VPC Peering	Transit Gateway
Topology	Point-to-point (full mesh needed)	Hub-and-spoke (centralized)
Transitive routing	NOT supported	Supported (via route tables)
Cross-Region	Yes (inter-region peering)	Yes (TGW peering)
Bandwidth	No limit (AWS backbone)	50 Gbps per attachment
Cost	Data transfer only	Per-hour + per-GB (more expensive)
Scale	Manageable up to ~10 VPCs	Scales to 5,000 attachments

Decision: <10 VPCs with simple connectivity? → VPC Peering (cheaper). >10 VPCs or need routing control? → Transit Gateway (scalable).

🔒 AWS PrivateLink

Purpose: Expose services privately without traversing the internet
Interface VPC Endpoints: ENIs in your VPC that route to AWS services or third-party services
Endpoint Services: You expose YOUR service via NLB + PrivateLink for consumer VPCs
No VPC peering required: Consumer and provider don't need overlapping CIDRs or routing
Cross-account: Provider can whitelist specific AWS accounts or org principals

NEW (Nov 2025): Cross-Region PrivateLink — Interface VPC endpoints can now connect to services in OTHER Regions. This removes the previous "VPC endpoints are regional-only" limitation. Major architecture simplification for multi-region designs.

🏘️ Shared VPCs (VPC Sharing)

Mechanism: AWS RAM shares subnets from a central networking account to participant accounts
Owner account: Manages VPC, subnets, route tables, NACLs, IGW, NAT Gateway
Participant accounts: Launch resources (EC2, RDS, Lambda) into shared subnets
Isolation: Resources in shared subnets can communicate unless security groups restrict
Benefits: Fewer VPCs, centralized networking, reduced IP address consumption

Analogy: Shared VPCs are like an office building where the landlord (owner) manages the building infrastructure (network), but tenants (participants) bring their own furniture (workloads) into assigned floors (subnets).

🏗️ Network Architecture Patterns

Centralized Egress

Single NAT Gateway/Firewall VPC. All spoke VPCs route internet traffic through TGW to central egress.

Centralized Ingress

ALB/NLB in shared services VPC. Route to spoke VPCs via TGW or PrivateLink.

Inspection VPC

AWS Network Firewall in dedicated VPC. TGW routes all inter-VPC and egress traffic through it.

Service VPC Pattern

Shared services (AD, DNS, CI/CD) in dedicated VPC. Expose via PrivateLink or TGW routing.

💻 Demo: PrivateLink Endpoint Service

# Create VPC Endpoint Service (provider side)
aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns arn:aws:elasticloadbalancing:...:net/my-nlb/xxx \
  --acceptance-required

# Create Interface VPC Endpoint (consumer side)
aws ec2 create-vpc-endpoint --vpc-id vpc-consumer \
  --service-name com.amazonaws.vpce.us-east-1.vpce-svc-xxxx \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-xxxx --security-group-ids sg-xxxx

# Accept endpoint connection (provider side)
aws ec2 accept-vpc-endpoint-connections \
  --service-id vpce-svc-xxxx --vpc-endpoint-ids vpce-xxxx

🧪 Knowledge Check

Q1: A company has 50 VPCs needing connectivity with network segmentation between prod and dev. Which solution is most appropriate?

A) VPC Peering (full mesh) B) Transit Gateway with multiple route tables C) PrivateLink D) Shared VPCs

B) Transit Gateway with multiple route tables — At 50 VPCs, full-mesh peering is unmanageable (1,225 peering connections). TGW with separate route tables for prod/dev provides scalable, segmented connectivity.

Q2: What change did cross-region PrivateLink (Nov 2025) enable?

A) PrivateLink over the internet B) Interface endpoints connecting to services in other Regions C) Gateway endpoints across regions D) PrivateLink without NLB

B) Interface endpoints connecting to services in other Regions — Previously, VPC endpoints were strictly regional. Cross-region PrivateLink removes this limitation, simplifying multi-region architectures without needing TGW peering just for service access.

📝 Module 5 Summary

TGW Advanced

Peering (cross-region), Multicast, Connect (SD-WAN). Route table segmentation for isolation.

PrivateLink

Private service access via ENIs. No peering needed. NEW: Cross-region support (Nov 2025).

VPC Sharing

RAM shares subnets. Owner manages networking. Participants launch resources. Reduces VPC sprawl.

Patterns

Centralized egress/ingress, inspection VPC, service VPC. Design for your scale and security needs.